# 


’  j# 


;.:  ‘jfe 

’  -v.  ‘  ' 

*•••'.*:  i--  ** 


00 


o 

<SJ 


if) 

m 

r— 


! 

D 


< 


cv 

o 


L.U 


c~3 

HKiMian- 
••  -  ' 

C3 


S3 


,  .•  .-*vr;  J V  .. 


*1 1  V  -  . 


;•„  ‘ : 

•  : 

■■ 

vVP'-- 
.  ■< 

-  iaflrai'  ».  ■ 

•'.  >"*•:).  k,- 


;  f„  •  :-$■■■  * 


a#  . 


•v  ’■r,:V 


, 


■•*.0  Vi!. 


■  ■  •>'. 

\/; 


siS^RK'S' 

’  a3£. 


?■•;.'  •  (S.  , 

-#-■>  .  •  •■  •».  -.*V. 


«*-*£F,X 


■■■•■ 


rf 


REPORT  ON 


TEACHING  ADA 
(Revised) 


"  tjiij 

■■ 

v' ‘.in’ 


f 


APPROVCD  FC  P"  DC  ROcASc; 
DISTRIBUTION  13  UNLIMI1ED  (A) 


-t* 


OTIC 


%  JUN  1  7 1965  ;  II 


c*? 


\  «/s> 

\l 


SCIENCE  APPLICATIONS,  INC. 


D’^TT.  BUTTON  STATED" : 


~7;r  ";■  S  T 


A.  ioi  public  reload  t 

Distribution  JnUroii'  i 


M 


rv 

* 

»•>  .  _  V" 


Ji-r-”- 


■ 

,U'fi  '  .  . 


f  .  .'fl 

l  *■&?-■■■■  i-:  '.: 

MBi 


■  V  3Crr-  ‘V  f  -fel; 

V-*-  *  W 

* *  i*  ...  -. 


v\." 


-v,.vS. 


0  : 


REPORT  ON 


TEACHING  ADA 
(Revised) 


APPROVED  FO7'  PU"UC  RELEASE; 
DISTRIBUTION  13  UNLIMITED  (A) 


s 


DTIC 

ELECTEI 


JUN  1  7 1985 


SAI-81-313-WA  / 


March  1980 


Revised 
December  1980 


Accession  For 

~NTIS  GRUkl  jEf 

DTIC  TAB 

Unannounced  □ 

Justification _ 

By - 

Distribution/ 

_ Availability  Codes 
Avail  and/or 
Dist  Special 


Russell  J.  Abbott 
Associate  Professor 
Department  of  Computer  Science 
California  State  University 
Northridge,  California  91330 


This  report  was  supported  by  the  Defense  Advanced 
Research  Projects  Agency  under  DARPA  Order  No.  3456, 
Contract  No.  MDA903-80-C-0188 ,  monitored  by  the  Defense 
Supply  Service,  Washington,  D.C.  The  views  and  con¬ 
clusions  contained  in  this  document  are  those  of  the 
authors  and  should  not  be  interpreted  as  necessarily 
representing  the  official  policies,  either  expressed 
or  implied  of  the  Defense  Advanced  Research  Projects 
Agency  or  the  United  States  Government. 


ATLANTA  •  ANN  ARBOR  •  BOSTON  •  CHICAGO  •  CLEVELAND  •  DENVER  •  HUNTSVILLE  •  LA  JOLLA 
LITTLE  ROCK  •  LOS  ANGELES  •  SAN  FRANCISCO  •  SANTA  BARBARA  •  TUCSON  •  WASHINGTON 

Science  Applications,  Inc. _ 

1710  Goodridge  Drive,  McLean,  Virginia  22102 


Teaching  Ada 


Hussell  J .  Abbott 

Dept,  of  Coirputer  Science 


California  State  University 


Northridqe,  Ca.  91330 


Tel.  213-885-3398 


Teaching  Ada 


Page  1 


■ftfcsisa cl 

Two  experiments  to  teach  Ada  in  Computer  Science  classes  are 
reported.  It  is  concluded  that  Ada  should  not  be  taught  simply 
as  another  programming  lanquage.  Instead,  Ada  shoula  be  embedded 
within,  and  taught  as  a  tool  for,  a  coherent  program  desian 
methodology.  A  continuation  of  the  second  experiment  continues 
during  the  Fall  '80  semester. 
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This  report  is  divided  into  5  sections: 


1 . 


Summary  - 


This  section  contains  a  suirirary  ot  the  lessons  learned  from 

the  experiment  and  the  conclusion  to  be  drawn. 

J 


r 


K 


2 .  Ada  — 

This  section  Discusses  features  of  Ada  from  the  point  of 

teaching  difficulty. 

J 

3.  Discussion  — 

This  section  discusses  the  recommended  approach  to  Ada  and 
contrasts  it  with  traditional  approaches  to  teaching  programming 

languages. 

) 

4.  Course  Summary  — 


i . 

jv 


This  section 
courses  taught  du 
concludes  with  a 


contains  more 
ring  the  Fall 
discussion  of 


complete  information  on  the 
*79  and  Sprino  '80  semesters, 
the  course  in  progress. 
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5.  Motivation 

This  section  contains  a  1  1/2  hour  presentation  which 
outlines  a  program  design  philosophy  and  provides  a  motivation 


tor  nany  ot  the  constructs  of  Ada 
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This  section  presents  a  suirirary  of  the  lessons 
an  experimental  project  to  teach  Ada  in  (a)  a  first 
Science  graduate  class  and  (o)  a  Junior  level  class 
design.  It  also  includes  the  conclusion  drawn  from 
experiment. 


learned  from 
year  Computer 
is  program 
the 


1.1  Lessons  Learned 
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Ada  can  be  a  difficult  lanauaae  to  teach.  There  are  3  main 
problems. 

a.  Ada  has  a  number  of  features  which  make  it  confusing. 

These  should  be  given  special  attention  by  the  instructor. 
(Section  2.1  lists  some  of  these  features.) 

b.  Ada  is  a  formidable  languaqe.  The  presentation  of  Ada 
should  simplify  it  for  the  novice  user.  (Section  2.2 
presents  an  approach  to  such  a  simplification.) 

c.  Much  of  Aoa  is  intended  to  support  a  program  design 
philosophy  rather  than  programming  as  such.  These  features 
are  difficult  for  students  to  accept  if  presented  simply  as 
programming  constructs.  (Sections  3  and  5  oiscuss  this 
issue. ) 

d.  In  order  to  teach  Ada  as  a  design  language  it  is  first 
necessary  to  develop  a  coherent  approach  to  program  design. 
no  such  approach  is  available  in  concrete  enough  terms  to 
permit  its  teachinq.  (Sections  4.2.3  -  4.2.6  address  this 
issue.  The  current  semesters  course  begins  to  rectify  the 
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q  situation.) 

e.  in  order  to  teacn  program  design,  it  is  necessary  to  teach 
>•  program  specification.  Design  cannot  reasonably  be  taught 

^  in  a  vacuum.  If  there  is  no  specification,  there  can  be  no 

design  —  for  there  is  nothing  to  be  desiqned  if  there  are 
no  requirements  from  which  to  work.  So  to  do  a  complete 
job,  it  is  necessary  to  develop  a  complete  methodology 
leading,  in  an  integrated  way,  from  requirements  to  design. 
Ada  would  be  most  profitably  taught  within  such  a  full 
e=  program  development  framework.  (Section  4.2.8  addresses 

this  issue.) 
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1.2  Conclusion 

Ada  should  not  be  taught  as  just  another  programming 
language.  Instead,  Ada  should  be  presented  within  the  context  of 
a  well  developed  program  design  methodology. 
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2.  Asa 

This  section  discusses  features  of  Ada  from  the  point  of 
view  of  difficulty  of  teaching,  while  a  number  of  features  of 
Ada  are  reviewed,  this  section  is  not  to  be  taken  as  an  overall 
evaluation  of  the  language.  Only  those  aspects  of  Ada  which  are 
potential  teaching  trouble  spots  are  mentioned.  This  discussion 
is  based  on  preliminary  Ada  and  does  not  reflect  chanqes  made  in 
final  Ada. 


This  section  is  divided  into  2  main  subsections: 

2.1  Difficulties  in  teaching  Aaa 

2.1.1  General  Features 

2.1.2  Specific  Features 

2.2  a  view  of  Ada  to  facilitate  teaching. 


2.1  Difficulties  in  teaching  Ada 


2.1.1  General  Features 


Ada  has  the  following  general  features  which  make  its 
teaching  more  difficult. 

a.  Ada  appears  to  the  new  user  to  be  too  big  a  language. 

Without  guidance,  the  new  user  may  feel  lost  in  the  large 
number  of  desiqn  concepts  and  programming  features  Ada 
offers.  The  new  user  needs  help  in  determining  which  are 
central  to  the  language  and  which  can  be  put  off  urtil 


needed 
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h.  Ada  programs  tend  to  be  auite  lengthy  Ci.e.  wordy),  and  for 
that  reason,  more  difficult  to  get  one's  hands  arcunc. 

c.  Some  of  Ada's  features  are  difficult  to  understand. 

d.  A  supportive  programming  environment  does  not  yet  exist. 

Ada  is  enough  of  a  challenae  to  the  new  user  by  itself. 

The  environment  must  not  maxe  it  more  difficult  tc  work 
with  Ada. 

2.1.2  SDeclfic  Features 

The  following  specific  features  make  the  teachinq  of  Ada 
more  difficult. 


i  I 
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2. 1.2.1  Multiple  Instances  of  similar  things 

Ada  provides  multiple  ways  of  developing  many 
instances  of  similar  things. 

a)  Assays  of  objects 

b)  families  of  tasks  and  packages 

c)  families  of  entries 

d)  instantiations  of  generics 

e)  am tinie-nbiects  declared  to  be  the  same  type 

It  may  be  confusing  to  the  new  user  why  there  are 
different  means  for  achieving  similar  results.  In  all  of 
these  cases,  one  is  dealing  with  multiple  instances  of 
similar  objects.  Yet  each  of  these  features  has  its  own 
individual  properties  which  must  be  learned  by  the  new 
user . 
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It  iright  have  been  easier  it  packages  and  tasks  were 
types,  tor  example  as  in  SIMULA,  instead  ot  objects.  One 
would  then  use  them  by  declaring  objects  to  be  of  the 
desired  package  or  task  type.  This  would  eliminate  the 
need  for  families  and  for  many  of  the  uses  of  generics. 


2. 1.2. 2  The  overloading  of  language  constructs. 


Some  of  Ada's  constructs  are  used  for  multiple 
purposes . 


2. 1.2. 2.1  The  keyword  HEJ# 


The  keyword  HE*  is  used  for  three  functions  : 


a)  Allocation:  1:=  &£*  TREE  ; 

b)  Derived  types:  H££  A  15  a*Ew  INTEGER  ; 

C)  Generics:  £££££££££  SWAP  15  £££  EXChANGE (CHARACTER); 


These  three  uses  of  5£«  occur  at  three  different 
"times"  in  the  processing  of  a  program:  run  time, 
elaboration  time  and  compile  time  respectively.  The  use  of 
the  same  word  in  such  different  situations  may  tenc  to 
contuse  the  new  user.  One  of  the  difficulties  new  users 
frequently  have  with  programming  languages  in  general  is  in 
keeping  clear  the  distinction  between  the  various  phases  in 
the  processing  of  programs.  The  use  ot  a  single  keyword 
for  all  three  situations  may  compound  the  difficulty. 


k-v. 
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gj  2. 1.2. 2. 2  The  Keyword  £ii£L 

The  Keyword  k£££  is  used  for  two  functions  : 

■  a)  CASE  constructs 
d)  SELECT  constructs 

A  confusion  might  arise  in  that  one  of  these 
constructs  is  deterministic  and  the  other  is 
pseudo-non-deterministic. 

i 

2. 1.2. 2. 3  The  keyword  £JuSI£ICIE£ 

The  keyword  £ES1£1CJ££  is  used  tor  two  functions 

I 

a)  Visibility  from  inside  a  module  to  other  modules; 

b)  The  restricting  of  private  data  types  from  use  in 

■ 

assignment  or  tests  for  equality. 

These  two  functions  are  quite  different.  Again, 
use  of  a  single  term  may  be  contusing  to  new  users. 


the 
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2. 1.2. 2. 4  The  ZAC&AZL  construct 

The  PACKAGE,  construct  can  be  used  for  multiple 
purposes.  All  are  valid  uses  and  do  not  subvert  the  intent 
of  the  construct. 

a)  A  replacement  for  named  common? 

b)  Libraries  of  subroutines!  data  types  and  constants; 

c)  Encapsulated  data  types; 

d)  Isolated  modules  (e.q.  a  "symbol  table"); 

e)  Co-routines; 

f)  An  alternative  to  record-structured  data  types? 
q)  Abstract  Machines; 

h)  Levels  of  abstraction. 

It  might  have  been  better  (at  the  risk  of  expanding 
the  language  still  further)  to  identify  some  of  those 
functions  explicitly  and  provide  individually  named  program 
objects  for  them. 

2. 1.2. 2. 5  The  symbol  => 

The  symbol  =>  is  used  for  a  number  of  functions; 

a)  CASE  constructs 

b)  SELECT  constructs 

c)  Object  initialization 

d)  Parameter  passing 


e)  Representation  association 
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The  first  two  of  these  are  control  functions;  the 
second  two  are  assignment  functions;  the  last  is  a  general 
association  function.  While  the  first  four  are  also 
associations,  their  operational  uses  will  probably 
predominate  in  people's  thinking.  The  use  of  a  single 
symbol  may  be  confusing  tc  new  users. 

2. 1.2. 2. 6  The  keywords  £££  and  ysE 

The  keywords  £Oii  and  li££  appear  in  the  machine  linkage 
statement:  £C£  ...  £££...  .  They  also  have  separate 

functions  elsewhere  in  the  lanquage.  Again,  this  may  be  a 
source  of  confusion.  In  this  case,  however,  the  difference 
between  the  functions  is  so  great  that  the  confusion  is 
less  likely  to  be  severe. 

2. 1.2.2. 7  Summary  of  Overloaded  Constructs 

The  issues  discussed  in  this  subsection  were  all, 
presumably,  deliberate  deslan  decisions.  They  may  be  qood 
decisions;  but  they  are  also  potential  sources  of 
confusion.  If  the  same  word  or  construct  is  used  in 
multiple  places,  new  users  tend  to  believe  that  they  are 
dealing  with  the  same  concept.  In  some  of  these  cases, 
there  may  be  a  risk  of  significant  confusion  to  new  users. 
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2. 1.2. 3  Private  Data  types 


Compilation  requirements  force  private  data  types  to 
be  declared  in  the  visible,  specification  portion  of 
packages  and  tasks. 


This  is  confusing  in  that  it  is  not  clear: 

a)  from  the  point  of  view  of  the  packaqe  user,  in  what  way 
the  private  type  is  hi dden--since  it  is  plainly  visible; 

b)  from  the  point  of  view  of  the  packaqe  specifier  (l.e. 
the  person  who  provides  the  reauireirents  specification 
tor  the  package),  why  it  is  necessary  for  him  to  specify 
those  data  types.  As  the  person  responsible  for 
defining  the  functional  capabilities  of  the  private 
type,  he  is  not  supposed  to  need  to  be  concerned  about 
it's  implementation.  Yet  the  private  type  must  be 
declared  in  the  specification  portion  of  the  packaqe. 


2. 1.2. 4  Subtypes  and  derived  types 


It  may  be  a  source  of  confusion  when  one  should  use  a 
subtype  and  when  a  derived  type.  It  should  be  made  clear 
that  the  only  reason  to  define  a  subtype  is  to  impose  a 
range  restriction  on  an  existing  type  •-  if  it  is,  in  fact, 
correct  to  make  that  claim.  Derived  types,  in  contrast, 
have  much  more  siqnificanct  uses  and  are  motivated  by 
higher  level  methodological  considerations.  Yet  the  two 
type  aeclarations  appear  so  similar  that  this  significant 
difference  in  their  use  may  be  lost  on  new  users. 
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2. 1.2. 5  Pange  Expressions 


It  iray  be  confusing  in  which  contexts  range 
expressions  are  permitted.  They  nay  be  used: 

a)  In  array  declarations  and  elaborations. 

b)  In  array  slice  operations. 

c)  In  subtype,  derived  type  and  anonynous  type 
declarations. 

d)  In  object  initialization. 

e)  In  FGP  statements. 

1)  In  floating  point  and  fixed  point  declarations, 
q)  In  representation  specifications, 
h)  In  references  to  families. 


It  would  be  useful  to  develop  a  rule  of  thumb  of  the 
form  "range  expressions  are  permissible  whenever  ... 
Perhaps  the  blank  is  truly  filled  in  by  "whenever 
convenient."  Expereince  so  far  sugqests  that  this  might  be 
the  case.  <*e  have  not  had  sufficient  experience  to  enable 
us  to  make  that  assertion  with  complete  confidence.  See 
2.1.2.10  for  an  apparent  example  of  a  situation  in  which  a 
range  expression  and  a  type  name  for  that  range  expression 
are  not  freely  interchangeable. 


2. 1.2.6  visibility:  the  keywords  fc££2£J.CIU2  and  u&k 


The  visibility  features  may  be  a  source  of  confusion 


to  new  users.  The  keyword 


serves  both  to 
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restrict  visibility  (from  the  normal  ALGOL  scope)  ano 
extend  visioility.  It  may  be  contusing  that  Efcsixi cttA 
visibility  is  in  some  ways  qreater  that  unBesJLticlfia 
visibility. 

The  1aS£  clause  may  also  cause  trouble.  Its  utility  is 
not  as  great  as  one  might  expect.  The  11SL  clause  is  to  be 
applied  only  to  modules--unlike  PASCAL'S  Jtllii  or  SIMLA 's 
JJi£££ Cl.  So  It  is  not  a  general  "unwrappino"  function,  on 
the  other  hand,  ji-Si-  does  not  extend  visibility  in  any  way. 
Its  advantage  is  minimal. 

It  might  have  been  better  to  make  the  modules 
mentioned  in  a  list  US£d  by  default,  unless 

otherwise  specified, 

2. 1.2, 7  Proqrams  and  libraries 

One  of  the  most  frequent  questions  new  users  ask  about 


Ada  i  s 


what  does  a  complete  proqrarr  look  like? 
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It  is  a  source  ot  confusion  that  there  are  no  objects 
called  "proqrams".  The  library  environment  is  a  new  concept 
and  needs  careful  explanation  to  new  users. 

2. 1.2.8  The  term  "overloaded" 

The  term  "overloaded"  was  a  poor  choice.  "Overloaded" 
connotes  to  most  English  speakers  an  unacceptable 
condition.  An  overloaded  operator  in  Ada  is  not 
unacceptably  burdened  or  ambiguous.  The  mechanism  which 
supports  overloading  is  very  useful;  the  term  itself  is 
conf usinq . 

2. 1.2. 9  Advanced  programming  features 

Ada  includes  a  number  of  advanced  programming  features 
which  present  some  problem  in  teaching.  While  these 
constructs  are  important#  they  do  take  some  effort  to 
master. 

2. 1.2. 9.1  Exceptions 

The  mechanism  of  declaring#  raising  and  fielding 
exceptions  and  the  associated  flow  ot  control  are 
unfamiliar  to  most  programmers, 

2. 1.2.9. 2  Tasks 

The  creation  and  use  of  tasks  are  new  concepts.  New 


students  must  master  concurrency#  oueues#  asynchronicity, 
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pseuao-randomness  and  their  appropriate  uses. 

2.1.2.10  Array  declarations 

It  Is  unclear  when,  arc  to  what  extent,  array  bounds 
must  oe  declared.  For  exairrle: 

vector  lSm.atz.AH  (1..10)  at  integer; 
v  ;  vector?  —  is  apparently  ox,  but 

subtype  index  Is  Integer  laaqa  1..10; 
lype  vector  array  (index)  at  inteqer; 

v  :  vector;  —  is  apparently  not  legal 

—  because  the  array  bounds 

—  are  not  declared.  Yet 

Dins  vector  Is 
Recnto 

size  :  constant  index; 
v  :  AttAt ( 1 . . s 1 ze ) ? 

Frdm  } 

v  :  vector;  «•  is  ok  without  declarina 

—  a  value  for  size,  and 
v  :=  (10,(1. .10  s>  0  5);  —  is  legal  as  is 

v  :=  (100,(1.100  s>  0));  —  immediately  afterward. 

It  is  not  clear  )ust  what  does  have  to  be  known  at 
elaboration  time.  (These  examples  are  from  F.  wegrer, 


Prrwyr anna  1  pg  ;t  n  Ada  .  ) 


2.1.2.11  Elaboration  time 


host  programmers  are  familiar  with  the  concepts  of 
compile  time  and  rur.  time.  In  Ada,  the  concept  of 
elaboration  time  becomes  eaually  important.  This  is  a  new 
concept  ano  may  be  a  source  of  confusion  to  many  new  users. 

2.1.2.12  Token  disambiguation 

It  a  token,  for  example  GREEN,  is  declared  in  two 
types,  for  example  color  and  tratf ic-liqht ,  it  may  be 
necessary  to  specify  which  GREEN  is  intended  in  certain 
situations.  The  notation  created  tor  that  disambiguation 
is:  color (GREEN) .  This  functional  notation  is  reasonable 
when  considerea  as  an  extension  of  the  notation  tor  type 
conversion.  As  pure  disambiguation,  however,  it  is  really 
quite  awkward  since  no  function  is  being  applied.  It  might 
have  been  better  to  use  the  dot  notation,  color. GREEN, 
since  this  notation  is  used  elsewhere  for  referential 
disambiguation. 

2.1.2.13  The  Genetic  Facilities 

The  facilities  for  generics  are  among  the  most  contusing  in 
Ada.  Generics  are  neither  pure  macros  nor  are  they 
pre-compiled  modules.  The  notion  that  generics  are 
compiled  "as  much  as  possible"  creates  difficulties. 
Non-local  references  in  the  body  of  a  generic  are  bound  in 


the  scope  where  the  generic  is  compiled 


Vet  parameters  to 
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generics  are  bound  in  the  scope  where  the  oeneric  is 
instantiated.  And,  of  course,  parameters  to  the  resulting 
object  --  if  it  has  parameters  —  are  bound  in  the  scope 
from  which  that  pbject  is  referenced.  In  all  three  cases, 
objects  are  bound,  but  the  scopes  in  which  they  are  bound 
are  different. 

Secondly,  generic  declarations  are  ugly  and  hard  to 
read.  The  attempt  to  pass  function  specifications  as 
parameters  just  does  not  look  intelligible. 

Third,  generics  may  not  be  powerful  enough.  Consider 
a  generic  integration  function  (wegner,  p.157): 

«£D££iX  (lUfiClifia  F(> :  FLOAT)  return  FLOAT) 

luacilnn  integrate  (low, high:  float)  return  float  is 


If  the  user  has  defined: 

HiOe  RADIAN  Is  afi*  FLOAT; 
lUOCllao  SIN (X :PADI AN )  return  FLOAT  Is  i 
will  the  compiler  accept: 

laacllfla  INTEGRATESIN  is  U&M  INTEGRATE (SIN); 

To  do  so  reguires  that  It  keep  track  of  the  derived  type 
chain  leading  from  FLOAT  to  RADIAN  --  not  a  difficult  job, 
but  an  added  burdon.  if  the  new  function  is  accepted,  will 
the  parameters  to  it  be  reouired  to  be  PADIANs  or  will 
arbitrary  FLOATS  be  accepted? 


•  . 
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Finally,  generics  are  a  weak  torn1  of  a  needed 
facility,  see  2.1.2.15. 


2.1.2.14  The 
Dynamic 
language  for 


Lack  of  Dynamic  Types 

types  could  make  Ada  a  much  more  flexible 
many  purposes. 


2.1.2.15  The  Lack  of  Eval/Execute/Functional  Parameters 


For  many  purposes  it  is  necessary  to  be  able  to 
perform  one  of  the  three  facilities:  passing  functions 
dynamically  as  arguments,  an  "execute"  facility  or  an 

"eval"  facility.  In  the  particular  example  examined  in  the 

* 

Sprino  '80  class,  it  was  very  awkward  not  to  be  able  to 
construct  a  procedure/function/command  and  then  to  execute 
it.  See  4.2  for  more  details. 
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2.2  A  view  ot  Ada  to  facilitate  teachino 

Ada  features  may  be  diviaed  into  four  categories: 

a)  ALGOL-like  programming  language  features:  the  standard 
parts  of  the  language. 

b)  Programmer  conveniences:  renaming,  range  operations, 
parameter  passing  by  formal  parameter  name,  etc. 

c)  Advanced  computational  concepts:  exceptions,  tasking,  some 
of  the  object  declaration  features,  etc. 

d)  Desiqn  motivated  features:  modules  and  associated 
mechanisms,  the  typing  facilities. 

These  categories  call  for  different  teaching 
approaches . 

2.2.1  The  basic  language 

Tne  ALGOL-like  part  of  Ada  may  be  taught  in  the  standard 
way.  It  would  probably  be  a  good  strategy  to  introduce 
experienced  programmers  to  Ada  through  this  part  of  the 
language  so  that  they  develop  an  initial  sense  of  comfort  and 
familiarity  with  it. 

2.2.2  Programmer  conveniences 

These  should  not  be  tauaiJi  at  all.  An  attempt  to  teach 
these  will  only  overload  (in  the  bad  sense)  the  students.  The 
language  will  appear  too  big  and  with  too  many  features. 

These  programmer  conveniences  may  be  mentioned  casually  in 
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passing  it  the  opportunity  presents  itself. 

2.2.3  Advanced  features 

The  advanced  features  should  be  taught  semantically . 

(See  section  3  for  a  discussion  of  teaching  strateaies).  There 
ere  four  steps: 

a)  A  problem  is  presented  which  cannot  be  conveniently 
solved  with  standard  features, 
o)  A  discussion  follows  of  the  general  form  of  the  sort  of 
programming  construct  needed  for  that  problem. 

c)  That  general-form  orogramming  construct  is  used  to  solve 
the  problem  in  an  informal,  pseudo-dialect  of  Ada. 

d)  The  actual  Aaa  construct  is  introduced. 

Tn  this  way  the  need  for  the  construct  is  developed 
first.  Second,  its  use  is  demonstrated  and  integrated. 

Only  then  is  the  student  asked  to  learn  the  specific 
details  of  the  construct. 

Since  the  real-time,  and  other  advanced  features  of 
Ada  will  be  significant  in  determining  its  success  or 
failure,  these  should  be  tauaht  with  great  care. 


The  design  features  of  Ada  are  very  important  to  its 
successful  use;  they  should  be  well  tauaht. 

The  Aca  design  features  should  rot  be  tauqht  as 
programming  constructs.  In  and  of  themselves,  they  do  not 
contribute  to  the  operational  solution  of  a  programming 
problem.  The  declaration  of  a  derived  type,  tor  example, 
does  not  bring  a  program  any  closer  to  achieving  its 
operational  qoals. 

The  most  reasonable  way  to  teach  the  design  features 
of  Ada  is  first  to  teach  a  design  philosophy.  Only  then 
should  one  introduce  the  features  of  Ada  which  support  that 
philosophy.  Section  3  elaborates  on  this  concept  further. 
Section  5  is  a  1  1/2  hour  presentation  which  sets  the  stage 
for  such  an  approach. 
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3 .  HAscassaaiu£i,,si&aifiaigs.^tfl£.lgacnlaa-i:xaa£affittIafl 

The  teaching  of  programming  has  evolved  throuah  two  stages. 
During  the  first  stage,  the  teaching  was  syntax  based;  during 
the  second  stage,  the  teaching  was  semantics  based.  It  is 
suggested  that  to  do  an  adequate  job  of  teaching  Ada,  a  third 
approach  is  reouired.  In  this  approach  the  teaching  should  be 
design  based.  This  section  provides  a  brief  review  of  these 
three  teaching  strategies. 


3.1  Syntax  based  Teaching 

The  original  approach  tc  teaching  programming  tended  to 
focus  fairly  heavily  on  the  syntax  of  the  programming  language 
under  discussion.  Students  were  taught  the  format  of  the 
statements  in  the  language--i.e.  where  the  commas  go,  and  the 
rules  for  forming  variable  names.  It  was  implicitly  assumed 
that  once  one  could  write  syntactically  valid  statements  in  a 
languaae,  it  would  be  easy  to  write  semantically  meaningful 
programs.  Of  course  this  approach  was  not  successful.  One 
can  teach  a  student  the  syntax  of  a  language  and  he  will  still 
have  no  idea  now  he  should  use  any  particular  construct  or 
even  why  the  construct  was  invented  in  the  first  place. 


t 
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3.2  Semantics  Based  Teachinq 

In  reaction  to  the  failure  of  the  syntax  based  approach, 
teachers  developed  a  semantics  based  teachinq  approach.  Using 
this  approach  one  focusses  explicitly  on  the  semantic  concepts 
availaole  in  the  programming  lanauage.  The  syntax  is  brouaht 
in  only  as  necessary  and  as  a  vehicle  to  express  the 
semantics . 

Using  this  approach,  one  would  teach  the  semantics  ot 
looping,  for  example,  and  then  discuss  the  DO  statement  (in 
Fortran)  as  the  syntactic  construct  to  be  used  to  express 
looping.  Similarly,  one  would  discuss  the  notion  of  program 
variables  (as,  tor  example,  names  ot  boxes  into  which  values 
can  be  put)  and  only  secondarily  discuss  the  rules  concerning 
the  spelling  of  variable  names. 

It  one  follows  the  semantics  based  approach  to  teaching 
programming ,  one  can  usually  get  across  the  main  features  of  a 
programming  lanquage  by  considering  the  following  aspects  of 
the  language. 

a)  Objects  and  Data  Types 

what  are  the  rre-defined  and  proarammer  definable, 
program  accessible,  objects  which  the  lanauaoe  makes 
available.  If  they  are  grouped  into  classes,  what  sorts  of 
thinas  are  they  and  what  oc  the  classes  represent.  That 
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is,  what  are  the  data  types,  if  any. 

b)  Operations 

what  operations  can  be  performed  on  these  objects.  In 
what  ways  can  they  be  manipulated  by  facilities  built  into 
the  language.  Normally  these  include  at  least  the 
arithmetic  operations  and  assignment. 

c)  Control  Structures 

What  facilities  does  the  languaqe  provide  for 
organizing  and  controlling  the  operations. 

d)  lnput/Cutput 

what  facilities  does  the  language  provide  for 
communication  with  the  outside  world. 

e)  other  Features 

what  other  facilities  does  the  language  provide.  This 
cateaory  includes  services  provided  by  the  language  as  well 
as  lanauaae  features  like  visibility  rules  and  parameter 
passing  modes. 

3.3  Design  Hased  Teachlnn 

It  one  were  to  follow  the  semantics  hased  approach  to 


teachlnn  Ada,  one  would  find  that  areas  a)  rejects  arc  e) 
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Other  Features  had  grown  considerably  trom  even  closely 
related  languages  like  Pascal.  Category  c)  Control  Structures 
would  also  have  grown,  but  to  a  rr.uch  lesser  extent.  Compared 
to  Pascal,  for  example  : 

a)  Oojects  include  an  enormous  amount  of  new  information  about 
data  types.  There  is  an  entire  new  "time,"  elaboration 
time,  in  the  processing  of  programs  which  becomes 
important. 

c)  Control  structures  include  the  new  control  structures  for 
exception  handling  and  tasking, 
e)  Other  Features  include  a  great  deal  of  new  information, 
including  packages,  scope  rules  and  all  the  proarammer 
conveniences  defined  in  Ada. 

* 

In  order  to  teach  Ada  successfully  a  higher  level  approach 
is  needed.  For  just  as  syntax  alone  is  not  sufficient  for  the 
motivation  and  use  of  semantic  constructs,  the  motivation  and  use 
of  the  Ada  design  constructs--especial ly  the  new  information  in 
categories  a)  and  e)--ls  not  generally  evident  from  their 
semantics . 

3.3.1  Teaching  Strategy 

Syntax  was  the  Initial  focus  of  teaching  programming 
because  without  correct  syntax,  one  cannot  write  a  program 
which  will  run.  because  of  that  undeniatle  fact  ct  life, 
when  the  teachlna  focus  shifted  to  semantics,  syntax  still 
had  to  be  accommodated.  The  accommodation  is  simple:  it 


Teaching  Aca 


Page  2f 


is  explained  tnat  there  are  syntactic  constraints  in 
writing  programs  and  tnat  they  will  be  explained,  tut  that 
they  are  on  a  lower  level  cf  importance  than  semantics. 

A  similar  approach  may  be  followed  in  a  design  based 
approach  to  teaching.  It  is  explained  that  the  specific 
semantics  of  Ada  must  be  understood  in  order  to  write 
correct  Ada  programs,  but  that  it  is  the  design  concepts 
that  drive  the  use  of  the  semantic  constructs  (in  the  same 
way  as  it  is  semantic  concept  which  drive  the  use  cf 
syntactic  constructs). 

3.3.2  Ine  Mindamental  Desiqn  Constructs 

what  are  the  desiqn  concepts?  There  are  a  number  of 
design  qualities  which  are  now  generally  considered 
important  for  proqrans.  The  two  most  inclusive  and  highest 
level  are  and  caxxcciogss .  If  a  prcaram 

posseses  both  ot  these  qualities,  most  ot  the  other  design 
qualities  follow. 

In  addition,  it  is  just  these  two  basic  desiqn 
qualities  which  motivate  most  ot  the  Ada  features  rot  found 
in  most  other  languages. 

Basically,  the  teaching  approach  to  Ada  should  start 
with  understandabi lity  and  correctness  as  basic 
requirements.  These  requirements  should  be  used  to  derive 


desiqn  techniques  such  as  strona  typlna,  data  tyre 
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4.1  First  Year  Graduate  Course  in  Programming  Langauge  Semantics 
(Fall  '79) 


4.1.1  Course  Organization 

Ada  was  Included  in  a  first  semester,  graduate  course  in 
programming  language  semantics.  Normally,  the  course  explores 
operational  models  ot  several  programming  languages.  This 

i 

semester  about  half  the  time  was  spent  discussing  Ada.  The 
SJGPLAN  versions  of  the  Preliminary  deference  Manual  and 
Fationale  were  used  as  texts. 

K 

The  topics  scheduled  along  with  their  associated  sections  of 
the  manuals  are  shown  in  table  1.  Only  the  first  seven  topics 
^  were  actually  covered  in  class.  The  teachina  approach  reported 
above  had  not  been  developed  by  the  time  the  class  was  taught. 

The  actual  class  was  organized  more  along  the  semantic  lines  than 
along  design  lines. 
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Table  1 


1 . 

Types 

P  3  » P  4  *  Rfe 

2. 

Statement s/Operations 

P4,P5,R3 

3. 

SUDrout ines 

P8,P6,R7,R9 

4. 

Exceptions 

P 1 1 ,  F  1 1 ,  R 1 2 

5. 

P acxaqes 

P7,P8,R8,R9 

b. 

mul ti-Taskinq 

P9,R4 

7. 

Generic  Types 

P 1 2  ,  B 1  3 

8. 

Library  System 

P6,R9,P10 

9. 

Input /Output 

P 1  4  ,  B 1 5 

10 

.Numbers 

P3 ,  R5 

11 

.Program 

PI  ,F2,R14 

Note  :  P  -  Preliminary  Reference  Manual 


l 


R  -  Rationale 

Numbers  shown  are  section  numbers 
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4.1.2  Ada  Interpreter  in  Ada 

It  was  originally  the  intent  of  the  course  to  teach  Ada  by 
developing  an  Ada  interpreter  written  in  Ada.  That  goal  was  not 
achieved. 


The  approach  to  that  project  was  to  presume  the  existence  of 
a  parsed  Ada  program  available  in  the  torin  of  a  parse  tree.  The 
job  of  the  project  was  tc  write  a  program  which  would  take  that 
parse  tree  as  input  and  execute  the  program  it  represents. 

4. 1.2.1  Pepresenting  the  parse  tree 

To  explore  Ada  "types"  we  examined  the  problem  of  defining  a 
type  NODE  to  be  used  in  representing  the  parse  tree. 


Our  approach  to  representing  the  parsed  program  tree  was 
(  1)  to  create  an  access  type  called  NODE  to  represent  each  node; 

and  2)  to  follow  the  grammar  more  or  less  directly  from  the 
«•'  manual. 


t 
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0  2i££  LEFT_HAND_SlDE_SYMbCL  15  <A11  the  left  hand  side 


grammar  symbols> 


11££  NODE  15  A£C£55 


££££££ 


NODE-TYPE  :  £££52152  LEFT— HAND— S IDE— SYMBOL ; 
£15£  MODE-TYPE  £E 


££££  <LEFT_ HAND— SIDE— SYMBOL>  =>  <B1GHT— HAND— SIDF->; 


=  > 


=> 


£££  £A5E 


£55  ££££££ 


Where  <RIGHT— hAND— SIDE>  is  represented  as  follows  depending 
upon  the  form  cf  the  associated  grammar  rule.  The  following 
shows  the  various  allowable  forms  of  grammar  rules. 


VY 


3-> - 


L 


it 
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1.  Grammar  rule  A  ->  p  c  L) 


Clause: 


A  =  >  HLQilkL 


B. PART  :  node  lb)  ; 

C. PAHT  :  NODE (C )  i 

D. PAPT  5  NODE  CD)  ; 


E„P APT  :  NODE(E); 


£Alll.ii£CJj£Ii 


2.  Grammar  rule  A  ->  B  I  C  I  D 


JaiiLL  Clause: 


A  =>  OFFSPRING  :  NODECB  I  C  I  D) 


3.  Grammar  rule  A  ->  Terminal 


Clause: 
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kU££  A  =>  LITERAL  :  STRING 
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4.  ArDitrary  repetition  (indicated  py  M*  and  *)*  in  the 
grammar ) . 


I  ■ 

i ; 

i * 

i  i 


A  =>  (B>  is  represented  by 

Jfai4£A  A  =>  Ai&&l(NATUFAi')  NODE  (B ) 

(Note  that  any  constructs  of  the  form  <A...B>  can  be 
replaced  by  (C>  and  C  ->  A...B.) 

5.  Optional  ccirponents  (indicated  by  *1*  and  in  the 

grammar  are  always  included  in  the  node.  (If  the  component 
does  not  exist  in  the  actual  situation,  the  value  of  the 
component  is  simply  liuLl). 


6.  Key  words  are  not  Included  in  the  tree.  (Their  purpose  is  to 
permit  parsing.)  ' 


I  (  7.  Minor  liberties  are  taken  with  the  grammar  to  simplify  the 


situation 
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As  an  example,  consider  rule  5.4  in  the  grammar: 


IF-STATEMENT  ::= 

If.  <CCNDITICN>  ££££  <SEQUENCE-OF_STATEMENTS> 
<£1SEIE  <COWDITION>  I£E£ 

<SECUENCE_GF_£TATEMENTS>> 
f£l££  <SECllENCE.OF.STATEMLKTS>] 
EJjfl-IE; 

The  node  type  representation  is: 


i  1 


> 


i  r 


£Jd£&  IF_STATEMEM  => 

IF.PAPTS  :  £££££( NATURAL)  fl£ 

££££!££ 

CONUITIGN-PAPT  J  NODF(CONDITION); 

THEN_PART  :  NODE  (SEQUEMCE_OF.,STATEA'ENTS  )  .* 
£££_££££££ 


t  U 


It  seemed  clear  after  worfcinq  with  the  grammar  for  a  while  that 
1£££  node  could  be  defined.  It  also  seemed  clear  that  actually 
to  do  it  would  be  a  long  and  tedious  job. 


the  design  of  programming  languages  in  general. 

4. 1.2. 4  Use  of  the  AdaTE  Facilities 

Many  attempts  were  made  to  use  the  AdaTE  test  translator, 
we  lacked  familiarity  with  it  and  with  the  various  intermediary 
systems  required  to  gain  access  to  It.  we  were  never  afcle  to 
make  constructive  use  of  it. 
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4.2  Junior  Level  Course  in  Proqram  resign  CSprino  and  Fall  '80) 

Tnis  was  the  appropriate  course  in  which  to  teach  Ada. 
Although  the  first  trial  was  not  perfect,  it  brought  to  light  a 
nurrber  of  points  which  should  be  incorporated  in  future  courses. 

4.2.1  hacK.ground  to  the  Course 


The  intent  of  tnis  course  is  to  teach  program  design  to 
students  who  have  a  reasonable  facility  with  programming  tools . 

It  follows  two  years  in  which  students  learn  the  basics  of 
programming.  It  has  as  prereaui s i tes  three  Sophomore  courses  and 
three  Freshman  courses. 

Introduction  to  Algorithms 

A  first  course  in  programming  using  a  high  level 
language . 

Introduction  to  Computers 

A  first  course  in  computer  organization  ••  i.e. 
assembly  lanquage  programming. 

Lata  Structures 

An  introduction  to  data  structures  and  their 
implementation. 

&Q£itiQBtQZ&-ii££iliXL£&e,Dl,£ 

Computer  Ornani zat ion 

An  introouction  to  computer  organization  and 
systems  programming.  Students  write  a  simple 


assembler  and  an  emulator  for  a  PLP11  type 
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H  machine. 

Concepts  of  Programming  Lanquages 

A  survey  of  program* ing  language  concepts  and 
B  facilities  as  provided  by  a  variety  of  high  level 

programming  lanquages. 

Introduction  to  File  Organization 

An  introduction  to  the  storage  of  large  amounts  of 
information  outside  the  direct  control  of  a 
proqram. 

i 

This  background  gives  our  Junior  students  two  solid  years  of 
training.  They  have  been  exposed  to  most  of  the  basic  tools  of 
programming,  lhey  are  taught  top  down  desian  and  structured 

I 

pr oqrammlnq  techniques  as  part  of  their  normal  proaramminq 
courses.  This  background  would  qualify  them  for  jobs  as  program 
implementers :  given  a  description  of  a  desired  module  (requiring 

r 

up  to  about  bOO  lines  of  HCL  code),  they  could  design  arc  produce 
a  reasonable  implementation. 

,  These  students  have  not  had  experience  with  larqe  programs. 

The  proarams  they  build  in  developing  their  assembler/emulator 
grows  durinq  the  semester  into  quite  a  tig  proqram.  Hut  the 
separate  pieces  are  given  to  them  one  by  one.  They  do  net  have 
to  worry  too  much  on  their  own  about  how  they  tit  together. 

The  Program  Desian  course  in  which  Ada  was  used  is  intended 
to  teach  techniaues  tor  dealing  with  programs  too  larae  to  keep 
in  one's  neaci  all  at  once.  This  seems  to  te  the  perfect  course 
in  which  Ada  (as  aistlnct,  for  example,  from  Pascal )  is  uniouely 
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valuable.  Ada's  Pectcage  construct  is  ideal  for  larae  rroqrair 
oesign.  In  addition,  it  is  just  tnis  situation  --  i.e.  in  which 
the  program  under  consideration  is  too  big  to  hold  in  one's  mind 
all  at  once  --  tor  which  Aoa  was  designed. 

4.2.2  Course  Entrance  Test 

Althouah  the  prerequisites  to  the  course  are  tairlv  rigorous,  it 
often  is  the  case  that  students  do  not  come  fully  prepared.  In 
an  attempt  to  calibrate  the  level  ot  preparedness  of  the 
students,  the  following  examination  was  given. 

Students  were  given  copies  of  Chapter  1  ot  [wegner].  They 
were  told  to  read  sections  1,2,4,5,6,6,9,10  and  11  from  that 
chapter.  They  were  told  to  write  down  any  specific  items  they 
did  not  understano,  They  were  told  they  would  be  quizzed  on  the 
material.  The  next  week,  they  were  told  to  hand  in  their  list  of 
questionable  items.  Then,  with  no  assistance  they  were  given  the 


followina  quiz 
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Answer  the  following  ouestions.  If  any  pertain  to  any  of 
the  items  you  nave  marked  as  not  understandable,  mark  that 
■  question  "deleted,"  You  have  20  minutes.  The  auiz  is  open  hook. 

£xux:xumx£  Simple-add  JLs 
x,y,z:  inteqer; 

jafeflAxi 

get(x); 

get l v ) ; 

r 

z  : =  x+y; 
put(z); 

£ud 

I 

1.  The  variables  x,v  and  z  are 

la)  local  variables  to  the  procedure; 

(h)  formal  parameters  to  the  procedure; 

(c)  global  variables  to  the  procedure; 

2.  Tne  character  means 

la)  subtraction 

lb)  nothing;  it  is  part  of  the  name 

3.  khat  does  the  construct  "2  10"  in  the  followirq  mean 

£ax  i  JLc  7  . .  10  laac 

la)  2  raised  to  the  power  10 

(o)  tte  range  of  integers  from  2  to  10  inclusive 

lc)  the  range  of  real  numbers  from  2  to  10  inclusive. 
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4 .  In 

Hbbcbbulb  Sort  (a  :  1b  cut  vector)  Is 
the  words  "1b  out"  rear 

(a)  the  vector  a  is  not  originally  sorted 

(р)  the  vector  a  ray  be  accessed  by  the  procedure 

and  ray  also  be  changed  by  it 

(с)  the  vector  a  ray  have  components  interchanged  by 


the  procedure 
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5.  Trie  basic  progratr  unit  In  Ada  is  called  a  "program"  and 
is  generally  of  the  for* 

h&alu 

<declarations> 

<stateirents> 

£ad 

(a)  True 

(b )  False 

6.  The  formal  parameters  tc  a  functio.  ray  be  declared  ±x 
out  and  rray  be  modified  by  the  function  to  return  additional 
information  to  the  caller  of  tne  function.  (True  cr  False). 

7.  Consider: 

£ackaoe  Fath-f unctions  Is 

iu act Aon  sin(x:real)  xxiuxs  real 
Xu ccl-tca  cos (x: real)  xxluxc  real 
Xuactxaa  tan (x: real)  xcJLuxa  real 

Emu 

The  above  packaae  specification  gathers  together  the  names 
of  tne  functions  sin,  cos  and  tan.  Their  actual  definitions 
are  taken  from  the  nath  library  of  math  functions  as  cart  of 
trie  run-time  support  of  the  language.  (True  or  False) 

B.  An  operator  is  overloadec  if 

(a)  it  nas  more  than  one  interpretation 
(o)  it  has  too  many  interpretations. 


9.  ine  relationship  between  a  package  sreci f lcatlor  and  a 
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package  bcoy  is 

(a)  the  body  defines  the  things  that  were  declared  in 
the  specification 

(b)  the  body  uses  the  things  that  were  declared  in  the 
specification  (as  a  procedure  body  uses  the  parameters 
and  local  variables). 

10.  If  a  data  type  is  declared  pr 1  naif  in  a  package 
specification,  it  is 

(a)  available  for  use  ty  the  user,  but  its  components 
are  not  directly  accessible 

(b)  not  available  for  use  by  the  user 

(c)  available  for  use  by  the  user  if  given  permission 
by  the  detiner. 

11.  A  task  in  Ada  i s 

(a)  a  program  unit  which  can  run  concurrently  with 
other  program  units 

(d)  a  well  defined  component  of  a  large  proarammina 
project  which  can  be  set  off  by  itself  using  the 
stepwise  refinement  aoproach  to  program  design 

12.  An  d£££££  statement  permits  a  task  to  accept 

(a)  data  from  another  task 

(b)  control  fror  another  task 

(c)  both  of  these 

(d)  relther  of  these 


(d)  all  of  the  above 
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13.  The  purpose  of  the  construct 

SdPCJt 

jhbeo  <condition>  =>  accept  ... 
at 

fcpea  <conditlon>  =>  accept  ... 

£pp  Select 

la)  to  enacle  a  task  to  be  available  for  calls  from 
multiple  users  of  the  task 

(b)  to  select  the  one  (and  only  one)  condition  among 
all  those  indicated  which  is  Itue  and  then  to  perform 
the  accept  statement  associated  with  it. 


. 

K 


K 


tz 


The  students  were  told  that  this  test  was  not  going  to  be 
used  in  determining  their  final  grade.  They  should  consider  it 
as  a  readiness  examination.  The  level  of  this  course  presumes 
that  they  are  more  or  less  capable  of  reading  the  assigend 
material  on  their  own  and  determining  what  they  did  understand 
and  what  they  did  not  understand.  It  turned  out  that  the  test 
was  a  fair  predictor.  The  students  who  scored  below  7  generally 
got  C*s  or  worse.  All  the  a»s  in  the  course  were  earned  by 
students  who  scored  10  or  better.  But  some  of  the  high 
performing  students  fell  off  later  and  one  of  the  poorer  scoring 
students  did  earn  a  H. 


«”>  ’_•>  w  .»  v  "-w  ny :  v  irajn 


E 
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The  results  of  the  test  were: 

Ivnnihpr  rrrrgrf 


13 

12 

11 

10 

9 

8 

7 

6 

5 

4 

3 

2 

1 

0 


4.2.3  Intended  audencies  tor  courses  in  Ada, 


0 

3 
0 

4 

5 

10 

5 

C 

3 

3 

0 

1 

0 

0 
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There  are  probably  three  types  of  audiences  tor  serious  Ada 
courses  --  i.e.  courses  which  are  rrore  than  just  a  brief 
executive  overview  of  what  Ada  can  do  for  a  large  systeir.  These 
three  audiences  are:  programmer  manaqers,  experienced 
programmers  and  novice  programmers. 


In  at  least  the  first  two  of  these  cases,  it  seems  that  the 
appropriate  focus  should  be  on  the  larae  scale  program  design 
issues:  programmer  managers  should  certainly  be  concerned  about 


i 


•-  .V 

*-■  s 


’.V 


r 
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^  proarair,  design;  experienced  programmers  generally  nave  cesion  as 
their  greatest  weakness.  Novice  programmers,  however,  need  more 
■S  than  design;  they  need  the  experience  of  writing  concrete 

^  programs.  Otherwise  they  don't  develop  a  feeling  for  what 

programming  is  all  about.  But  even  in  this  case,  the  program 
design  philosophy  should  Infuse  the  more  concrete  programming 
ideas  taught. 

So  the  ouestion  becomes;  hew  does  Ada  work  in  a  course  in 

Program  Design? 
fci 


4.2.4  Difficulties  in  Teaching  Program  Design 


The  primary  difficulty  in  teachinq  program  design  is  that 
there  is  no  clear  definition  of  what  a  proper  program  design 
should  be.  It  is  much  easier  to  teach  programming  than  program 
design  in  that  one  can  at  least  run  the  program  and  see  if  the 
answer  is  right.  Design  is  much  more  qualitative;  one  cannot 
give  an  automatic  test  to  apply  to  a  design. 


l  t  In  addition,  we  have  no  standards  tor  design,  we  have 

•  o 

developed  standards  for  programs:  sinoie-entry/single-exit 

> 

,’v  control  structures,  hierarchical  module  structure,  "small"  module 
i"  size,  stronoly  typed  data  object  usage,  etc.  There  are  not 

[  »\  similar  standards  tor  design.  So  the  two  basic  problems  one 
faces  in  teaching  design  are: 

!  ^  1)  what  is  a  program  design? 

•.'!  I.e.,  how  would  you  know  one  if  you  saw  one? 

h  «» 

!  2)  what  dualities  characterize  good  proaram  designs? 
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The  first  Question  is  the  irost  revealinq.  There  is  nc 
agreement  in  the  software  community  as  to  what  one  is  producing 
when  one  does  software  design.  There  does  seeir  to  be  agreement 
about  levels  of  design.  There  are  two:  architectural  or  top 
level  and  detailed.  There  also  seems  to  be  agreement  about  a 
characteristic  of  oetailed  design:  it  can  be  turned  into  a 
program  with  a  minimum  of  effort. 


But  the  important  question  is  about  the  architectural  level 
of  design.  Here  there  is  no  consensus.  It  is  interesting  to 
note  that  the  DoD  has  standards  for  program  specifications  Call 
program  specifications  must  be  written  in  a  certain  format)  and 
for  proqrams  themselves  (all  programs  must  be  written  to  certain 
formats).  But  there  is  no  standard  for  desiqn:  anything 
apparently  will  do. 


H  In  Wegner's  869  pace  book,  "Research  Directions  in  Software 

Technology  (Ed.  by  P.  wegner,  hit  Press,  1979)  there  does  not 

v* 

seem  to  be  one  definition  of  what  a  software  design  should  be, 

my 

t  In  the  software  engineering  literature  there  is  little  agreement 

about  design.  There  are  the  notions  of  "Top  Down  Design," 

>•;  Structured  Design,"  "Michael  Jackson  Design,"  "Parnas  Design," 
and  others.  To  a  great  extent,  these  are  as  much  design 
t»rhrigui»t  as  cesign  definitions.  As  techniques,  one  can  infer  a 
desiqn  definition  implicit  in  them.  However,  their  goals  seem 
for  the  most  part  to  be  to  find  ways  to  produce  code  in  an 
orderly  manner.  This  is  different  from  an  explicit  qoal  of 

-‘2 


producing  a  design  itself  as  an  end  product 


Most  of  the  work  in 


Ki  ’V  .  _> 


p 

•  Teaching  Ada 


Page  49 


:  D 


I  i 


i  K 


i  t 


.  t 


i  L 


program  design,  then,  seems  to  take  the  word  "design"  as  a  verb 
(and  hence  attempts  to  define  a  process  by  which  one  designs  and 
codes  programs)  rather  than  a  noun  (in  which  the  design  itself  is 
a  desired  product).  And,  in  fact,  one  hears  a  great  deal  about 
"program  design  methods"  and  a  lot  less  about  "program  design 
standards. " 


4.2.5  what  is  a  design? 


A  design  is  a  description  of  the  thina  designed.  A  design 
shows  the  structure  of  the  object.  According  to  Webster's  a 
oesign  is:  "a  plan*"  "a  delineation,"  "a  preliminary  sketch," 

"an  underlying  scheme  that  governs  functioning,  developino, 
unfolding,"  "the  arrangement  of  elements  that  make  up  a  structure 
or  a  work  of  art." 


Software  design  is  a  description  of  the  structure  and 
functioning  of  software,  what  is  necessary  to  show  that?  There 
are  at  least  four  sorts  of  structures  relevant  to  software: 
control,  oata,  interface  and  framework.  A  software  design  must 
delineate  all  four. 


1)  Control  structure. 

Control  structure  is  the  most  familiar  of  these  notions  to  those 
involved  with  software.  The  control  structure  of  a  piece  of 
software  is  the  paths  which  the  processor(s)  which  perform(s)  the 
software  may  take  through  it. 


2)  Data  Structure. 

The  data  structure  of  a  piece  of  software  is  the  ways  in  which 


l 
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data  is  stored  within  it  and  the  paths  which  data  iray  follow 
through  it. 


3)  Interface  Structure. 

The  interface  structure  of  a  piece  of  software  is  the 
organization  of  the  interactions  between  the  software  and 
elements  external  to  It. 


I  ■ 


4)  Framework. 

Beyond  these  three  sorts  of  "flow"  structures,  there  is  a  fourth, 
and  perhaps  more  important  structure.  That  is  the  structure  of 
the  framework  of  concepts  and  definitions  upon  which  all  the 
others  are  based.  It  is  this  fourth  level  of  structure  --  the 
static,  skeletal  structure  within  which  the  others  function  — 
that  is  at  the  heart  of  design. 

It  is  the  goal  of  this  course  to  teach  program  design,  where 
design  is  defined  in  the  terms  just  discussed. 


i  t 


4.2.6  Lessons  Learned  about  Teaching  Design 

1)  Students  have  a  hard  time  developing  a  feeling  for  -what 
one  wants  in  a  design. 

2)  Students  have  a  hard  time  producing  a  desiqn  in  any  sort 
of  logical  way.  Often  they  seem  to  "guess,"  i.e.  to  write  down 
something  without  an  understanding  of  what  it  means. 

3)  Students  have  to  be  taught  about  the  notion  of  a  black 
box  module. 


v..\. 


vAi’- 


'  V-  V-  *_• 


v-  .'■^sas-v-  • 
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4)  Aaa  is  a  useful  language  to  use  for  expressing  software 


design. 


5)  It  is  necessary  to  teach  system  specification  before 
teaching  design.  It  is  necessary  to  teach  systeir  requirements 
definition  before  teaching  systeir  specification. 


6)  It  is  very  difficult  to  use  Ada  (or  any  formal  language) 
without  an  easy-to-use  processor. 


4.2.7  Problem  Assignments 


4. 2. 7.1  First  Assignment 

The  first  assignment  was  to  specify  packages  for  the  "pile," 
"tree,"  and  "counter"  objects  introduced  in  the  "programming 
methodology"  talk  (see  Section  5.), 


SBS&SXS 


EscESttfi  CCUNTER-PACKAGE  Is 

l¥fl£-UjllttIEli-l£-BXisaX£ ; 

Prnrediire  increments:  la  am  COUNTER); 
Prnrprinrp  Reset (C!  BBl  COUNTER); 

EuacllBB  Value (c:  counter)  Exlaxii  REAL; 


PflyaPe  COUNTER  is  n£S  INTEGER; 

Eud  COUNTER-PACKAGE,* 


Eackaae  Tree-stuff  is 

laa£  tree  is-cxissis; 


:i_ia  tree,  l,r;  bjuX  tree); 


V 
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Ilxxxxd xx£  oiscara(t:  ix-xxl  tree); 
txxxllxx  is_leaf(t:  tree)  xfiXxxx  BOOLEAN; 
£XlX£l£  XiUi£  tree  lx  ££££££ 


£££XX£ 


tree.or.leaf  :  ( T ,  L ) ; 

Cax£  tree_or„leaf  al 

_ LX££ 

j.X£X-L-=^-1^X_2221222-££1£-2222222 


£E£.££X£ 


£X£-X££OXX 


xxx  tree-stuff; 


Pile  lx 


£X£  tree»stuf  i 
HUi£  pile  ix-cxlxalx ; 

jUixxIIcb  is-empty  (p;pile)  xflluto  boolean; 

£X£££££££  reset  Co:  Ix-xxl  pile); 

cx£££d£££  put-orupile  (t;  lx  tree,  p:  lx_cx 1  pile); 
xxx£££xx£  Duli.of f.pile  (t:  xut  tree,  p;  lo-xxi  pile); 
£x1x£X£,X^P£  stack  lx 


axxaxll— .11)  Ul-xl  tree; 


£x£  Pile; 


Althouah  the  assignment  was  for  the  students  to  qive  only 
the  speci f  ications  for  the  three  packaqes,  the  bodies  were  worked 
cut  in  class.  The  class  seemed  much  more  comfortable  if  they 
could  see  how  the  fcooies  would  work.  Otherwise,  they  felt  a  lack 


of  concreteness.  (It  should  be  noted  that  although  the  example 
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ir  section  5  trade  use  of  a  "pile”  data  type,  this  solution 
defines  the  single  pile  required  as  an  encapsulated  data  object.) 


counteh-package  is 

Exflflflfluxs  Increment  (c:  ia_flai  COUNTED  is 
ijfifiic  c  :=  c  +  l  £££  ; 

EXflCSXflXC  FESET  (CJ  ifl-flUi  COUNTED  is 
iflfliD-C-iS-la-Sflfl  ; 


■LuflCXiflO-lLALHE-lci-I 


PEAL  is 


Ii£ai£_ii£££££  c  £X£ ! 


cad  Counter-Packaoe; 


£uc.fcaa£-ii£dS  tree- stuff  is 


iuDCiiii.il  is-leat(t:tree)  xflJLuxx  BOOLEAN  is 
t.tree-or-leaf  =  L; 

Exflcsfl use  trear-in«.half  ( t :  ia-aui  tree,  l,r:  sui  tree) 


Jcflflifl 


A sscxi-flfli  is-leat(t); 
1  : =  1. 1 ; 


r  :  =  t .  r  ? 


£Dd  tear  -in-half; 


flxac£dux£  oiscardCt:  ifl.cui  tree)  is 


t  : =  Duii ; 


flue  tree-stult; 


EflfluflUS-DfldS  Pile  is 


iUflCliflfl  is-enrtv  (piPile)  xsiuxc  boolean  is 


top  =  0 
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H  k£MC£Uut£  Dut.on.pile  (t:  jLc  tree)  lx 

top  :=  top  +  1; 

g  PC  too)  :=  t; 

t  : =  null ; 
zza; 

utuc££iu££  pu 1 l_of f _p i 1 e  (t:  out  tree)  lx 
t£uj.n 

£tt£tt  top  >  0; 

i 

t  :=  p(top); 
top  : =  top  -  l; 
ooo ; 

I 

CiXJC£flAiJUB  reset  ±&  top  :=  0; 

top  :  loi£Q£X-.x£xia£  o  ..  loo  0; 

|"  £uti  Pile; 

4. 2. 7. 2  The  Second  Assignment 

The  next  assignment  was  to  do  the  same  job  (i.e.  create 
packages)  for  another  problem.  This  problem  was  ore  that  one  of 
the  other  instructors  uses  in  his  version  of  the  class.  He  has 
written  a  set  of  notes  for  the  class.  [Gilbert)  Those  notes  have 
teen  used  as  a  class  text,  so  we  used  some  of  the  problems  from 
them . 

10£ -lOO-lOO 

"Hocky  Racoon  Kecords  Is  trying  to  improve  record  sales. 
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For  this  purpose ,  the  company  has  put  toq ether  a  list  of  names 
and  aodresses,  and  has  hired  the  Random  Sampling  Co.  to  interview 
the  people  on  tnis  list  every  month.  Peocle  on  the  list  will  be 
grouped  into  tour  categories,  according  to  their  age  Cage  <  20  or 
aae  >  19)  aicd  sex  (male  or  female),  so  that  the  company  can 
exarring  the  various  aroucs  who  buy  their  records. 

"Lach  person  on  the  list  will  be  askec  to  state  which 
records  of  t tie  Top  Forty  he  or  she  would  rank  1st,  2nd,  3rd,  ... 
9th,  10th.  This  information  toaether  with  the  interviewee's  name 
ana  address,  will  be  punched  on  cards  for  input  into  a  program. 

"The  proaran  is  desired  which  will  process  these  cards  and 
print  out  various  lists: 

(a)  to  find  out  which  records  are  popular 

(1)  a  list  of  the  Tor  40  titles,  in  alphabetical  order, 
with  the  number  of  times  the  title  was  mentioned. 

(2)  a  list  of  the  10  most  popular  titles,  in  order 
of  their  popularity. 

(b)  to  find  out  who  are  the  best  record  customers 

(3)  a  list  of  all  people  who  mentioned  at  least  5  out 
of  tne  titles  in  list  2 

(4)  four  separate  lists  (one  for  each  of  the  four 
categories),  each  list  namino  all  interviewees  in  the 
category  who  rano  1st  one  of  three  titles  most  popular 
with  people  in  the  category." 
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Again,  the  solution  was  found  by  first  aenerating  an 
Intuitive  solution  --  including  a  data  flow  graph.  Then  the 
objects  and  operations  in  the  intuitive  solution  were  to  be 
trapped  onto  Ada  packages. 

It  turned  out  that  all  that  was  needeo  was  a  single  package 
with  the  following  types  and  operations. 

IyXfiS  (Private) 

Title,  Response,  Person,  Table. of. titles ,  Table.of. People, 

Table, of. Responses 

toexallax-s 

Sort.t  ltles(Ix_01LI  lable.of.Titles) ; 

Add.to.Mentions (  lx  Responses,  Tn,_  gnt  tablfc.of.tltles ) ; 

Caiculate.popular ity (  lx  tab le.of.responses , 

lx-xxl  tabie.ot.titles); 

pi ck-best.chooser s (lx  title-table, 

lx  response-table, 
xxl  peop le. table ) ; 

pick.niost.representative.of.category (lx  title. table, 

lx  response. table , 
out  reople.taole ) ; 

4. 2. 7. 3  Exercise  and  Quiz  on  data  structures 

It  turned  out  that  the  students  in  the  class  had  a  iruch 
poorer  packaround  in  defining  data  structures  than  they  should 
have  had.  we  spent  a  good  part  of  the  next  few  classes  workina 
on  data  structures  and  on  Ada  facilities  tor  their  expression. 
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|  Follo*ina  that,  this  auiz  tested  what  they  had  learned. 

QklZ 

^  This  quiz  represents  a  package  to  keep  track  of  information 

about  stuoents,  teachers  and  courses.  The  three  data  tyres  are 
defined: 

Type  student  is  access 
££££££ 

name  :  strina; 
t 

current-gca:  gpa; 

units_atter,pted ,  units  _passed:  units; 
updated  :serester; 

I 

courses:  azzay  (natural)  a 1  course; 

--  all  courses  ever  attempted 
£&4.££C£X£i ; 

r 

pype  course  «Ls  access 
££X££d 

narre:  ticket; 

i 

--  a  5  dlalt  ticket  number 
teacher ;  instructor; 
offered:  semester; 

--  all  sections  ever  offered  are  kept  in 
the  data  base 

students:  d££dy  (natural)  c± 

teccsd 


person:  student 
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evaluation:  grade 

--  entered  at  the  end 
—  of  the  course 

e nrt  r ecor d : 

Anri  r»pnl;ri 

XX££  instructor  lx  xccxxx 
xecxxX 

name:  string; 
title:  rank; 

courses:  arr^y  (natural)  al  course; 

£m3_X££fl£d 

aackaae  school.info  lx 

Xxfi£  student  Is  exixaXx 
xxo£  instructor  lx  cxlxxXxx 
LiiU£  course  lx  axlxxXxs 
Xvx£  ticket  lx  exlxxXfii 

✓ 

litpfi  semester  lx  exlxxXxs 
Xxc£  rank  lx  fixlxxlxi 

iJixcllaa  f ind(name:string)  x£tuxo  student; 
XuacXlaa  iind(name:  string)  xxliixc  instructor; 
XaacXlaa  tindCnbr:  ticket)  xxXxxx  course; 


prnrpriiirp  update_student  (per  son :  student, 
time:  semester); 


axlxxXx 

Xxx£»xxax_lx 
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iaOS.iicSSl.iS  ...  ; 
ISOS  semester  is  ...  ? 

pnri_  sr hnp ) . 1 nf n 


oaciSQe.boas  school. info  is 


luus  node  is  sccsss 
iscoid 

tree.type : 
cm ixsssii 
csss  tree.type  ci 

sOso  students  =>  value:  students; 
sOso  instructors  =>  value:  instructor; 
sisa  courses  =>  value:  course; 
snd.cass 

left,  right:  node  cull; 
soC.se case 


student-root:  node  :*  auii" 
instructor-root:  node  :=  auii; 
course.root:  node  :=  auii; 


iuacliaa  find  is  os*  gen_fird(str inq, student) ; 
luocliao  find  is  Css  gen.f lndcstring,  instructor); 
iaociico  find  is  css 

oen.f indtticket ,  cour,e); 


P  r  grp  an  r  p  update  (person:  student,  t ime  :  semester  ) 

is  ...  ; 


sad  scnool.info 
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1.  The  types  student,  course,  and  Instructor  could  just  as 
well  have  been  defined  as  non-access  types  (true  or  false: 
explain  your  answer). 

2.  Complete  the  definitions  of  the  type  ticker.  It  should 
be  with  a  subtype  of  integer  or  a  derived  type.  Explain  why  you 
are  making  the  choice  you  do. 


3.  Create  a  definition  for  the  type  rank  (in  the  instructor 
typej.  It  should  be  an  enumeration  type  which  can  take  or  values 
of:  Asst-prof,  Assoc-Prof  and  Full-prof. 


4.  The  package  tody  contains  three  trees  similar  to  the 
symbol  table  tree  in  the  the  symbol  table  package  in  (Wegner,  p. 
143).  In  shcool-into  there  are  trees  for  students,  instructors 
and  courses.  A  single  node  type  is  defined  with  a  variant  record 
structure . 


Rewrite  the  function  find  [wegner,  p.143)  so  that  it  takes  a 
student  name  as  input  ano  returns  the  student  if  found.  If  not 
found,  the  value  nui l  should  be  returned. 


5.  Since  there  are  three  trees  with  identical  structures,  it 
seems  reasonable  to  use  the  same  find  function  on  each.  But 
since  Ada  enforces  strong  typing,  problems  arise: 

a)  the  input  to  two  of  the  find  functions  are  strings 
(instructor  name  and  student  name);  the  input  to  the  other 


find  function  is  a  ticket  number  (for  course) 


r 
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(b)  the  results  returned  are  of  three  different  types: 
student,  instructor  and  course. 

This  is  an  ideal  situation  in  which  to  create  a  rir  function. 

Modify  the  answer  you  qave  for  (4)  so  that  it  is  a  qenerlc 
function.  The  two  aeneric  parameters  are  (a)  the  type  of  the 
input  to  the  function  and  (o)  the  type  of  the  output.  Name  the 
generic  fucntion  gen_find  so  that  the  find  functions  as  defined 
in  the  package  body  are  correct. 

6.  Complete  the  Exacaduca  update.  The  inputs  are  as  shown. 

Processing : 


|  1.  Look  through  the  list  of  courses  associated  with  the 

given  student. 

:'-c: 

2.  Select  those  whose  "offered"  copmpnent  matches  the  tieir 

B 

parameter. 

3.  Update  the  student's  units_attempted,  units.passed  and 

t  gpa  by  each  such  course. 

4.  Update  the  student's  "updated"  component  to  be  the  inut 

1-1  parameter. 

•1;  which  aaditional  type  parameters  have  to  be  completed?  Show 

how  you  would  define  them, 

£ 

r,s 
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Access  types  are  required  to  peririt  oDjects  to  point  to 
other  objects.  Students*  courses  and  instructor  all  point  ot  one 
another.  It  tne  types  vere  not  access,  each  ot  these  types  would 
have  to  be  embedded  within  the  definitions  of  some  of  the  other 
types.  E.q,,  courses  would  have  to  be  embedded  within  students. 
But  students  would  also  have  to  be  embedded  within  courses. 

2.  Derived  type 

ticket  lx  axx  integer  xaooe  1000C  ..  99999; 

Don't  want  to  permit  ticket  numbers  to  be  confused  with 
other  sorts  of  integers. 

3.  £¥&£  rank  lx  (Asst.prof,  Assoc.prof,  Full.prof); 

4.  Need  to  change  proaram  in  the  book  to  compare 

n  <  n. value. name 

This  tested  the  understanding  of  records  and  access  types. 

5.  ££££xl£  (2xc£  s,P;  tiiacilao  "<"(u,v:s)  leLuzm  boolean) 

■Lunclloo  gen.f indtname:  S,  root:  node)  xfiliixa  R  lx 

n:node  :=  root.type; 

bfealn 

&ad: 

6.  £xoced£X£  Update  ... 
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4.2.b  Requirements  and  Specifications 


After  reviewing  as  much  of  Ada  as  was  indicated,  it  seemed 
appropriate  to  bacx  up  and  look  at  the  problem  again,  (Ihe 


problem  is  how  to  design  programs.)  The  design  problem  is,  of 
course,  embedded  in  a  larger  problem:  the  program  life  cycle. 
Ke  spent  some  time  going  over  the  standard  waterfall  chart. 


In  order  to  ao  a  reasonable  lob  of  program  development,  four 
tasks  are  required: 


1)  define  the  user's  needs, 

2)  specify  the  computer  system  which  will  fill  those  needs, 

3)  desiqn  that  system, 

4)  code  that  system.. 


The  explicit  goal  of  the  course  is  to  teach  techniques  for 
step  3.  But  there  really  is  no  way  to  do  step  3  in  a  vacuum. 


There  is  no  way  to  design  something  without  knowina  what  it  is 
that  has  to  be  designed. 


Rpqn i rpgp &££ 


ke  spent  some  time  figuring  out  what  user  needs  ("requirements") 
were,  we  used  as  an  example  problem,  a  travel  agency  system. 

The  system  should  be  able  to  set  up  trips  for  travelers.  It 
would  have  to  deal  with  interconnection,  travel  preferences  (e.g. 
meal  types,  time  contraints,  etc.)  fare  calculations,  etc. 


We  spent  some  time  invest ioatinq  a  requirements  statement 
for  the  problem.  It  was  a  very  useful  exercies  for  ♦•he  students 
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to  see  how  much  information  has  to  be  developed. 


% 


r 


we  developed  a  general  framework  tor  a  document  in  which  to 
express  requirements.  Briefly  it  included: 

0.  Document  Overview  and  Conventions 

1.  Operational  Context:  purpose,  goals  and  world  model. 

2.  Data  Requirements 

3.  Functional  Requirements 

4.  Interface  requirements 

5.  Human  Factors 

6.  Performance:  timinq,  sizing,  loading,  accuracy 

7.  other  Constraints 


K 


•w" 
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we  didn't  incluoe  a  section  on  standards  because  the 
standards  are  not  really  a  part  of  the  program  specific 
information.  All  systems  should  be  designed  to  essentially  the 
same  design  and  programming  standards.  If  necessary,  there 

should  be  a  qeneral  reference  standard  which  can  be  invoked. 

\ 

Soac-llic  alioas 

Since  requirements  were  fairly  far  from  the  design  problem, 
we  went  on  to  discuss  specifications.  For  that  we  used  the  same 
document  format  as  for  the  requirements  but  included  in  it  system 
specifications  rather  than  user  goals.  The  essential  differences 
between  the  requirements  document  and  the  specification  cocuments 
are : 

1)  The  requirements  document  is  written  from,  the  point  of  view 
of  the  user.  It  speaks  in  user  domain  terms,  in  English, 
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about  user  domain  issues;  discusses  data  and  operations 
with  respect  to  the  user  organization;  and  has  as  its 
overriding  goal  the  expression  of  the  qoals  of  the  user  and 
his  organization. 

2)  The  formal  specification  is  written  froir,  the  point  of  view 
of  a  independent  outside  party.  It  speaks  in  matheirat ical 
terms  and  in  predicate  logic  notation  whenever  possible; 
discusses  data  and  operations  in  formal  terms  and  with 
respect  to  precisely  defined  interfaces;  and  has  as  its 
overriding  goal  the  expression  of  a  precise  description  -• 
i.e.  specification  --  of  a  system  which  will  satisfy  the 
goals  in  the  requirements  document. 

4.2.9  Final  Exercise 

One  more  exercise  was  given  in  the  course.  It  was  a  variant 
on  the  matchmaker  problem,  we  discussed  the  algorithmic  problems 
involved  and  then  concentrated  on  the  user  needs  ••  i.e.  we 
considered  what  an  actual  matchmaker  business  would  like  to  have, 
rather  than  worrying  too  much  about  the  computational  complexity 
cf  the  general  problem. 

4.2. to  Final  Froject 

For  the  final  project,  the  students  were  required  to  desiqn 
a  problem  for  which  Ada  is  not  well  suited.  The  problem  is  to 
build  one  or  more  packages  wnich  an  application  programmer  could 
use  in  developing  specific  application  programs. 
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we  decided  to  desiqn  a  general  araph  handler  to  inode  1 
possible  user  interaction  paths.  It  was  also  necessary  to  detine 
a  general  input  type  checking  irodule.  Here  Ada  was  not  easy  to 
use  unless  one  wanted  to  build  generic  modules.  In  addition,  we 
wanted  to  builc  facilities  to  construct  calls  to  unspecified 
input  processors.  Aoain,  Ada  was  difficult  to  use  because  the 
details  about  the  Incut  processors  would  not  be  available  until 
after  the  program  was  written.  That  information  would  be 
provided  by  the  application  programmers.  Ada  is  not  very 
suitable  in  that  one  cannot  build  procedure  calls  dynamically  and 
then  execute  them.  The  problem  was  worthwhile,  however,  since  it 
did  lean  to  some  useful  packages.  For  those  situations  in  which 
Ada  was  weak,  we  specified  augmented  capabilities  which  would 
make  the  problem  easier.  That  too  was  a  useful  exercise  in 
specification . 

The  general  outline  of  the  design  has  five  packaqes. 

Terminal  Screen.  This  package  is  a  specification  of  the  user 
terminal  screen.  The  actual  screen  is  assumed  implemented 
in  hardware. 

Terminal  Keycoarc.  This  package  specifies  the  user  keyboard. 

Terminal  Handler.  This  packeae  handles  the  user  input.  It 

groups  together  input  characters  according  to  formats  passeo 
to  it  from  the  graph  handler.  It  accumulates  a  number  of 
"items"  in  specified  formats  and  within  specified  ranges. 


Fach  such  collection  of  items  corresponds  to  a  single 
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"screenful"  of  information  --  e.g,  perhaps  a  form  or  a 
collection  of  responses  to  a  menu.  If  the  user  incut  does 
not  match  the  required  formats,  the  terminal  hanoler 
Interacts  with  the  user  to  help  him  correct  his  mistakes, 
when  the  user  Input  is  complete,  the  terminal  handler  hands 
the  input  collection  over  to  the  qraph  handler. 

Graph  handler.  This  package  is  the  central  controlling  part  of 
the  system.  It  follows  the  user  aroura  the  paths  provided 
by  the  application  programmer.  Each  application  provides  a 
qrapn  which  indicates  the  possible  user  interactions.  Each 
node  of  the  graph  is  associated  with  a  single  user 
interaction  sub-session  handled  by  the  terminal  hander. 

Each  such  node  has  a  collection  of  items  associated  with  it. 
These  items,  and  whatever  promptino  material  goes  along  with 
them,  is  passed  to  the  terminal  handler  for  display  to  the 
user  and  for  data  collection.  In  many  cases,  a  node  is  a 
menu  requiring  a  selection  by  the  user.  In  other  cases,  a 
node  is  a  form  to  be  tilled  in  by  the  user.  In  all  cases, 
the  graph  handler  receives  tne  input  back  from  the  terminal 
handler.  It  then  peckaqes  that  information  as  arguments  to 
a  procedure  call  associated  with  the  node  and  calls  that 
proceoure. 

Graph  Data  Base.  This  packaae  is  the  data  base  in  which  the 
various  graphs  are  stored.  Each  graph  corresponds  to  an 
application  package  and  is  rot  known  to  the  system  ahead  of 
time.  a  graph  may  be  any  seauence  of  nodes  and  eooes 
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siriiar  tc  a  graph  grammar.  That  is,  It  hay  have  subgraphs 
associated  with  some  of  its  nodes.  For  those  nodes  which 
correspond  to  user  selection  roints,  e.g.  menus,  the 
multiple  edges  leading  out  of  such  nodes  are  labelled.  The 
user  input  is  used  to  determine  which  exit  edge  to  follow. 

Application  Library.  This  packaae  represents  the  application 
packages.  It  has  one  entry  for  each  application  package 
operation  --  an  operation  is  associated  with  each  user 
interaction  node  and  is  called  by  the  qraph  handler  after 
receiving  input  from  the  user.  The  system  ooes  not  know 
about  these  operations  ahead  cf  time. 
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4.3  The  Fall  '80  Semester  Course 

Durinq  the  Fall  '80  semester  the  same  Junior  Level  Program 
Design  course  is  again  being  tauqht.  The  course  is  following  the 
recommendations  outlined  in  this  report.  Since  the  course  is 
still  in  progress  at  the  time  of  this  writing,  a  final  conclusion 
is  not  possible.  The  basic  outline  of  the  course  has  emerged: 

Fart  1. 

In  this  part  of  the  course,  a  great  deal  of  emphasis 
is  placed  on  two  foundation  stones: 

A.  Fundamental  Programming  Techniques,  Thesp  include  aata 
structures  and  recursive  programming.  For  the  most  part, 
this  is  review  material  and  is  covered  by  the  course 
prerecuisites. 

P.  Formal  Specifications.  In  this  part,  the  emphasis  is  on 
predicate  calculus.  A  great  deal  of  time  is  spent  on 
specifying  proqrems  formally  and  distinguishing  between 
what  one  does  in  specifying  a  proqram  versus  what  one  does 
in  realizing,  or  implementing,  a  proqram  to  satisfy  a 
specification.  This  is  a  relatively  new  corcep t  for  the 
students  and  it  takes  them  a  while  to  catch  on.  It  is 
also  fairly  difficult  for  them  to  aet  a  feeling  fcr  a 
specification  langauae  and  what  it  means  to  be  precise  in 
making  specifications. 


In  this  part  of  the  course,  students  are  introduced 
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to  tne  basic  iaeas  of  program  proofs.  They  are  taught  ho* 
to  take  a  specification  and  a  proposed  realization  and 
then  prove  that  the  proposed  program  does#  in  fact, 
implement  the  specification.  While  the  basic  ideas  behind 
program  verification  are  introduced,  the  course  does  not 
attempt  to  teach  the  subject  in  any  depth.  Prograrr 
verification  is  used  as  a  motivation  for  the  need  for 
precise  specifications  and  tor  well  oraanized 
implementations. 

Program  verification  does  serve  as  a  aood  bridqe. 
tor  students  who  are  comfortable  with  rronramminq ,  the 
idea  that  a  specification  can  be  linkea  to  more  familiar 
objects  (i.e.  programs)  helps  them  understand  the 
difference  between  specifications  and  programs  and  also 
helps  them  develop  a  facility  for  writing  specification. 

The  basic  ideas  behind  the  definition  and  use  of 
abstract  aata  types  in  specifications  are  covered  in  this 
part  of  the  course.  The  talk  from  section  b  of  this 
report  is  typical  of  the  material  covered  in  Part  1  of  the 
course.  The  book:  Jones,  C.H.,  Snftnarp 
b lgnr qui  Apprn^mr  Prentice  Hall,  1980  is  a  reasonable 
text  for  this  part  of  the  course. 

PAM  11. 


In  this  part  of  the  course,  the  tone  changes 
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Part  I  was  auite  formal  and  had  a  gocd  deal 
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of  notation.  It  focusses  mainly  on  small  programs  and 
their  specifications.  In  this  part,  the  course 
concentrates  on  reguirements  and  specification  for  large 
systems.  Again  there  are  two  parts. 

A.  Reguirements.  In  this  part,  the  idea  of  user  reouirements 
is  covered.  Reouirements  are  taught  as  the  user's  view  of 
what  the  intended  system  should  do  for  him.  Reouirements 
are  stated  in  user  domain  language,  are  about  user  coals 
and  present  the  user's  world  model. 

B.  Specifications.  In  this  part,  the  idea  of  formal 
specification,  as  covered  in  Part  I,  is  applied  tc  large 
systems.  In  Part  I,  only  small  functions  and  operations 
were  specificied.  Here,  systems  which  are  large  enough  to 
need  requirements  are  dealt  with.  The  main  topics  are  (1) 
how  to  translate  requirements  which  are  stated  in  user 
domain  terms  and  are  about  user  goals  into  more  formal 
notation  and  language,  and  (2)  how  to  trace  from  the 
requirements  to  the  specification  tc  be  sure  that  the 
goals  defined  by  the  requirements  will  be  met  by  the 
system  described  in  the  specification. 


PART  III 
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The  earlier  parts  of  the  course  do  not  have  a  great 
deal  of  emphasis  on  Ada.  Ada  is  used  as  the  example 
programming  language  in  Part  I.  (Put  Ada  is  used  more  or 
less  as  pseudo-code  or  as  a  variant  of  Pascal  and  no 
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atteirpt  is  maoe  to  teach  Ada  uex  ££.)  In  Part  2,  the 
notion  of  Ada  packages  is  introduced  on  a  very  informal 
basis  when  it  is  necessary  to  express  external  system 
specifications.  But  again,  Ada  as  such  is  not  central. 

In  this  third  part,  Ada  is  much  more  important.  This  part 
of  the  course  Is  about  system  architecture,  and  the  Ada 
package  facility  is  the  lanauaqe  used  to  express 
architecture.  Once  again,  there  are  two  sub-parts. 
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A.  The  Package/Module  Concept,  here  the  packaae  construct  is 
introduced  formally  and  the  visible/hidden  distinction 
emphasized.  A  lot  of  time  is  spent  discussina  the  various 
uses  to  be  made  of  packaaes,  and  it  is  emphasized  that 
these  uses  correspond  to  different  sorts  of  design 
components.  The  main  design  constructs  discussed  are: 
encapsulated  data  types  (abstract  data  types  are  taught  in 
Part  I),  encapsulated  data  objects,  abstract  machines, 
libraries,  tasks  and  levels  of  abstraction.  Each  of  these 
concepts  is  discused  and  its  use  developed. 

B.  System  Desian.  In  this  final  section  of  the  course,  the 
design  constructs  lust  discussed  are  loined  together  with 
the  formal  specifications  of  Part  II  B  to  show  how  large 
systems  can  be  designed  and  rigorously  justified.  In 
effect,  this  part  of  the  course  shows  how  large  packaqe 
specifications  (i.e.  the  sort  of  specification  resultina 
at  the  top  level  of  an  entire  system  specification)  can  be 
broken  down  and  implemented  in  terms  of  lower  level 
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packages.  This  process  of  "package  stepwise  refineirent' 
is  taught  in  tertrs  of  the  packaae  aesian  constructs 
presented  in  Part  III  A  of  the  course. 
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jg  5.  Introduction  to  Ada  Program  Desian  ►'ethodoloav 

The  presentation  which  follows  demonstrates  a  program  desiqn 
strategy  which  is  supported  by  Ada.  It  focusses  on  the  concepts 
P  of  Information  Hiding  and  Abstraction.  The  presentation  shows  how 
the  recommended  methodology  would  be  carried  out  on  a  particular 
program  desian  problem.  It  is  not  the  intent  of  the  presentation 
to  focus  on  the  problem  itself.  The  problem  is  only  a  vehicle  for 
pr esentinq  the  desiqn  strateay . 


THIS  TALK  PRESENTS  A  PROGRAM  DESIGN  METHODOLOGY.  THE  METHODOLOGY  IS 
BASED  ON  THE  CONCEPTS  OF  ABSTRACT  DATA  TYPES,  INFORMATION  HIDING  AND  LEVELS 

OF  ABSTRACTION. 


GIVEN  A  BINARY  TREE,  COUNT  ITS  LEAVES. 


THIS  BINARY  TREE  HAS  11  LEAVES,  I.E.  TERMINAL  "NODES".  THEREAREALSO 
INTERNAL  "NODES"  (A-J)  WHICH  ARE  NOT  LEAVES. 


(T,  AND  T0  ARE  THE  SUBTREES  OFT) 


THIS  WOULD  BE  A  TRIVIAL  PROBLEM  TO  CODE  IN  A  LANGUAGE  WITH  RECURSION. 
EVEN  WITHOUT  RECURSION  THIS  IS  NOT  A  DIFFICULT  PROBLEM.  WE  ARE  TAKING  IT 
HERE  ONLY  AS  A  VEHICLE  TO  PRESENT  THE  CONCEPTS  OF  ABSTRACT  DATA  TYPES  AND 
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CORRECTNESS  OF  HIGHER  LEVELS. 


TO  ACHIEVE  THESE  DESIGN  GOALS  WE  SHALL  DO  OUR  DESIGN  WITHIN  THE  FOLLOWING 
ADDITIONAL  CONSTRAINTS.  WE  WILL  USE  A  DESIGN  LANGUAGE  WITH  THESE  CAPABILITIES. 
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IN  OTHER  WORDS,  THE  ONLY  PRE-DEFINED  TOOLS  WE  HAVE  ARE  CONTROL  STRUCTURES 
SUCH  AS  IF,  CASE,  WHILE,  LOOP,  ETC.  WE  CANNOT  ASSUME  WE  HAVE  OBJECTS  OR 
OPERATIONS  GIVEN  TO  US. 


(VERY)  INFORMAL  STRATEGY  FOR  COUNTING  TREE  LEAVES 


TO:  ORIGINAL  TREE 
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15.  FINISHED.  THE  ORIGINAL 
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HOW  SHOULD  ONE  APPROACH  A  PROGRAM  DESIGN  PROBLEM? 


WHAT  ARE  THE  OBJECTS  BEING  MANIPULATED? 
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Cl  WHEN  THE  PILE  IS  EMPTY,  WE  ARE  DONE. 


THERE  ARE  A  TOTAL  6  OBJECTS 


WHAT  ARE  THE  OPERATIONS  BEING  PERFORMED? 


OPERATIONS 


INCR(C)  -  (TAKES  A  COUNTER  C  AND  ADDS  1  TO  III 


THIS  GRAPH  DOES  NOT  SHOW  A  SEQUENCE  OF  EVENTS  OR  ANY  TYPE  OF  CONTROL  ORGANIZATION. 
ALL  IT  SHOWS  ARE  1)  THE(fojFCTS^2)  THe|qPERATIONs3  AND  3)  WHICH  OPERATIONS 
ARE  (EVER  POSSIBLY)  APPLIED  TO  WHICH  OBJECTS. 


THE  CONTROL  FLOW 
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A  10P  DOWN,  STRUCTURED  PROGRAMMING  DESIGN  METHODOLOGY  MIGHT  HAVE  GOT 
US  TO  THIS  SAME  POINT.  USING  TOP  DOWN  DESIGN  ONE  WOULD  NOW  PROCEED  TO 
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THIS  CONCLUDES  THE  VERIFICATION  OF  THE  PROGRAM. 


IN  OUTLINE,  THE  ENTIRE  PROGRAM  APPEARS: 


1)  WE  HAVE  DEFINED  A  LEVEL  OF  ABSTRACTION  CONSISTING  OF  THE  SPECIFICATIONS  FOR  TREE, 
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PROGRAM  DESIGN  CONSTRAINTS 


CORRECTNESS  OF  HIGHER  LEVELS. 


HAVE  WE  SATISFIED  OUR  DESIGN  STANDARDS? 
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4)  THE  DESIGN  AND  IMPLEMENTATION  CHOICES  MADE  FOR  THE  LOWER  LEVELS  WILL  NOT 
AFFECT  THE  CORRECTNESS  OF  HIGHER  LEVELS. 
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INFORMATION  HIDING.  ABSTRACT  DATA  TYPES  AND  LEVELS  OF  ABSTRACTION 
PROVIDE  METHODOLOGICAL  CONCEPTS  AND  TOOLS  TO  SIMPLIFY  AND  RATIONALIZE 


